1. Field of the Invention
The preferred embodiments of the present invention relate to operation of computer systems. More particularly, the preferred embodiments are directed to calling basic input/output system (BIOS) routines in a computer system. More particularly still, the preferred embodiments are directed to determining the availability and the specific interrupt service number of BIOS routines in a computer system.
2. Background of the Invention
The heart of any computer system is the motherboard. The motherboard generally contains a microprocessor, main memory army, and various bridge devices which enable hardware and software components to communicate and perform their respective functions. Given the fact that there are many motherboard manufacturers, which may include any of an array of possible microprocessors, there is likewise an array of varying steps and procedures required for software to communicate with hardware. However, software applications, for example word processors and Internet browsers, are typically written for a class of computers without distinction as to a specific brand of computer system or the specific type of motherboard. Thus, some functions which software applications perform are abstracted (or taken away from the) software applications such that the specifics for each hardware implementation need not be embodied in the user-level software. The first level of abstraction between user-level programs and hardware typically takes the form of driver programs. Thus, rather than user-level software attempting to communicate directly with hardware, this software need only be programmed to communicate with a respective driver program. The driver program then is assigned the task of communicating with the hardware devices. Performing the task of communicating with hardware may take the form of calling basic input/output system (BIOS) routines to perform very specific tasks. While many BIOS routines are standard across all types of computing systems, most ROM BIOS manufacturers allow original equipment manufacturers (OEMs), companies who make the computers that consumers purchase, to define their own BIOS routines. The problem, however is keeping track of the many BIOS routines that an OEM may provide.
It has become customary in the art for one person within an OEM to take responsibility for keeping track of the BIOS routines added. That is, if a software developer needs to create a new BIOS routine, the developer contacts the person responsible for managing the added BIOS routines, the BIOS call owner, to request the next available services number. This services number is assigned to the exclusion of all others thereafter. In large corporations, merely finding the person who is responsible for managing the assignment of services numbers for new BIOS routines may be difficult. Moreover, once a BIOS routine has been created under a particular services number, it is very difficult to change or update the services number because of support for legacy driver software that may know the BIOS routine by interrupt category and services number only. Thus, it is possible that multiple assigned interrupt services numbers (a limited resource) may be allocated to multiple BIOS routines whose functions are only minimally different.
Outside the context of development and more in the context of operating software, it is difficult for device drivers, software typically responsible for executing BIOS routines, to determine whether a particular OEM-added BIOS routine is supported on a computer system. A first way to determine if a particular BIOS routine is supported is to simply call the BIOS routine and check the return status. Generally speaking, a return value of 86 h (86 hexadecimal) from a called BIOS routine is an indication that the BIOS routine is not supported. Calling the BIOS routine in an effort to determine whether that routine is available is dangerous in some cases in that the call to the unsupported BIOS routine may cause a computer system crash.
A second method for determining whether a particular BIOS routine is supported is to have the kernel level software (driver) which does the BIOS call first check a BIOS information table to obtain a BIOS version number, as well as the BIOS date, and compare the information to determine whether the BIOS supports the BIOS routine desired. This, however, cannot guarantee that in every circumstance a correct conclusion regarding support for a particular BIOS routine, and further may require a substantial amount of information to be hard coded in each driver for the comparison step, which significantly increases the footprint of the driver in main memory.
Thus, what is needed in the art is a mechanism to uniquely identify BIOS routines, as well as a mechanism to determine whether any particular BIOS routine is supported in a computer system, without the possibility of crashing the system in the determination process or requiring driver programs to keep large tables of information for compatibility checking purposes.